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ABSTRACT 


The conventional control and monitor 
software currently used by the Space 
Center for Space Shuttle processing has 
many limitations such as high maintenance 
costs, limited diagnostic capabilities 
and simulation support. These limitations 
have driven us to develop a knowledge- 
based (or model-based) shell to generi- 
cally control and monitor electro-me- 
chanical systems. The knowledge base de- 
scribes the system's structure and func- 
tion and is used by a software shell to 
do real-time constraints checking, low- 
level control of components, diagnosis of 
detected faults, sensor validation, auto- 
matic generation of schematic diagrams 
and automatic recovery from failures. 
This approach is more versatile and more 
powerful than the conventional "hard cod- 
ed" approach and offers many advantages 
over it, although, for systems which re- 
quire high speed reaction times or aren't 
well understood, knowledge-based control 
and monitor systems may not yet be appro- 
priate. 


INTRODUCTION 


Background of Problem 

The current Launch Processing System 
( LPS ) at the Kennedy Space Center (KSC) 
has the duty of checking-out and launch- 
ing Space Shuttle vehicles. The responsi- 
bility begins with testing the Orbiter's 
many systems in the Orbiter Processing 
Facility, continues through the assembly 
and check-out of the integrated vehicle 
(External Tank, Solid Rocket Boosters and 
Orbiter) and ends with final countdown 
and launch. The computing system which 
supports these tasks is a decade-old net- 
work of 15 consoles (1 console » 1 com- 
puter & 3 monitor/keyboard units) , a huge 
data-communications system (Front End 
Processors and common Data Buffers), and 


large Mainframes for data storage and 
retrieval, documentation and configura- 
tion control. The console computers them- 
selves have a 16-bit address bus, 64K of 
RAM and a single 80Mb Winchester disk. To 
provide a feel for the capability of this 
system, the total number of "Function 
Designators" (FD's) in the KSC database, 
which describe all commands and measure- 
ments, is approximately 95,000 including 
Cargo, Facility, Ground and Flight FD's. 
The actual number used for each launch is 
in the neighborhood of 40,000. 

LPS (Conventional) Software Approach 

The software applications running on the 
console computers used to check-out the 
Space Shuttle vehicle are written in a 
NASA-designed procedural language called 
Ground Operations Aerospace Language or 
GOAL. These GOAL procedures are conven- 
tional control and monitor programs spe- 
cific to the system the writer/engineer 
is responsible for and vary widely from 
system to system and even within a single 
system (due to the fact that many people 
participate in writing system test pro- 
grams) . The typical program is "hard-cod- 
ed" to the components and FD's of the 
system it controls and monitors, speci- 
fying exactly what steps to take in order 
to command any component to any desired 
state. 


LIMITATIONS OF LPS/CONVENTIONAL APPROACH 


Limited Diagnostic Capability 

The program's only ability to perform di- 
agnostics are of the failure tree sort 
which maps a restricted number of possi- 
ble failure conditions (pattern of mea- 
surements) to a probable cause, deter- 
mined by the engineer and then coded in 
GOAL. Naturally, a system of reasonable 
size makes the ability to do a complete 
tree search impossible. The number of 
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possibilities grows exponentially with 
each new component added. 

Limited Display Capability 

The user interface consists of character- 
based "display skeletons" with cursor 
keys for pointing and issuing commands. 
Systems are displayed as well as possible 
but the displays can not be dynamically 
reconfigured and are limited in number 
for each console. As in many applications 
today, much of the GOAL code is written 
to handle the user interface. 

Limited Data Retrieval Capability 

Data Retrieval is through a command-line 
interface with unforgiving syntax. Graphs 
of stored data are available but neces- 
sarily restricted due to the character- 
based display and screen size. 

Low-to-Medium Fidelity Simulation 

For application program testing and 
training, simulation is done off-line by 
software engineers on a system called 
Shuttle Ground Operations Simulator 
( SGOS ) in a custom simulator language. 
One problem is that the software engi- 
neers are often not familiar with the 
true operation of the hardware and it 
takes many iterations to get even the 
more basic functions working correctly. 


PROBLEMS RESULTING FROM CONVENTIONAL AP- 
PROACH 


Expensive to Maintain 

Because each application program is spe- 
cific to its system, any modifications or 
corrections in the equipment require the 
system engineer to individually change 
all applications and SGOS programs and 
retest and reverify them (usually a long 
process) before they are operating cor- 
rectly. 

No Sensor Validation 

One of the biggest and most-encountered 
problems seen during check-out of many 
systems is that of sensor validation. 
Many launches and tests have been delayed 
or aborted due to a sensor indicating a 
faulty component when, in actuality, the 
component was fine and the sensor or mea- 
surement channel itself was at fault. 
Some diagnostics can be written to help 
with this problem but, as stated earlier, 

it is impossible to handle all cases. 
Delays of this sort in the Space program 
have equated to millions of dollars. 

Additional LPS/Space Center-Related 
Problems 


Two additional problems, experienced 
system engineers reaching retirement age 
and accelerated launch schedules, are 
leaving relatively inexperienced person- 
nel to monitor and run the check-outs. 
These, combined with the problems above, 
result in both delays and errors in the 
day-to-day processing. 

Obviously, out-dated equipment plays a 
role in some of the problems listed. But 
replacing the hardware with no change in 
software except for the ability to have 
larger programs will not solve these 
problems. What is required is a much more 
intelligent control and monitor approach. 
We believe the knowledge-based or model- 
based techniques described here and ex- 
hibited in the Kennedy Space Center’s 
Knowledge-based Autonomous Test Engineer 
project (KATE) are a viable solution. 


The remainder of this paper will cover 

the following topics: 

The Model-based Approach - A discussion of 
our understanding of model-based con- 
trol, monitor and diagnosis and how 
we've applied these techniques to some 
of the problems at KSC. 

The KATE Implementation - A short status 
of the KATE project describing its ca- 
pabilities. 

Limitations - A description of the kinds 
of systems and situations the KATE 
shell may not be applicable to. 

Future - A summary of some projects relat- 
ed to the KATE technology and how we 
hope KATE will affect these other pro- 
grams . 


THE MODEL-BASED APPROACH 


Since our understanding of this approach 
is from an engineering perspective, not a 
fully comprehensive, academic one, this 
discussion will necessarily be limited to 
the work done in developing the KATE 
shell. Davis [1] and de Kleer [2] provide 
more complete information on model-based 
systems. The model-based approach is 
founded on the idea of describing a sys- 
tem of components in terms of its struc- 
ture and function, structure is how the 
components of the system are intercon- 
nected, for example "The output of tran- 
sistor one is connected to the inputs of 
transistors two and three". Function, on 
the other hand, tells us how the compo- 
nent operates in terms of relating inputs 

to outputs, i.e. a transfer function, and 
tells us how the component can be expect- 
ed to perform. For example "The output of 
transistor one is 2.5V when the input is 
above or equal to 1.0V and the output is 
0.0V when the input is below 1.0V" . This 
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explicit description allows us to effec- 
tively separate the system-specific 
knowledge from the procedural "smarts" 
which reason about the system's operation 
from the knowledge base. This dichotomy 
means physical system changes, such as 
replacing existing components or adding 
new components (both of which might 
change the behavior of the system) re- 
quire a very easy knowledge base change 
without impact to the procedural portion 
(the shell) of the system. This assumes 
the shell is robust enough to handle the 
new component. 

This approach is markedly different from 
rule-based control and monitor systems 
which are very specific to a particular 
system. The underlying approach to con- 
trol, monitor and diagnosis employed by 
these systems is really no different than 
the conventional approach described 
above. For diagnosis, rule-based systems 
use rules about the components to map a 
particular pattern of measurements and 
states into a probable cause. They don't 
really reason about why the answer is 
probable; such knowledge is simply writ- 
ten down by the engineer (where the real 
understanding is) and put into rules. 
Control is done in a similar manner. The 
options for getting a component to a de- 
sired state are decided by the engineer 
(using his internal model of the system 
and reasoning skills) and then committed 
to a rule-base. The major advantages of- 
fered by modern rule-based systems are 
their highly-developed user interfaces 
(they usually run on Lisp Machines) and 
development and graphics tools. 

Having the system described in a KATE- 
style knowledge-based format allows our 
shell to do the same kinds of things en- 
gineers do with the information. 

Monitoring 

Since the shell knows the values of all 
commands which control the system and how 
the components of the system work, it can 
derive the expected values of all objects 
(including measurements) by "propagating" 
the effects from the commands down 
through the knowledge base to the mea- 
surements. If these expected measurement 
values don't match the measured values 
coming in from the system there is either 
a malfunctioning component or an inaccu- 
rate knowledge base. Hopefully, the sys- 
tem's knowledge base has been carefully 
developed and matches the real hardware. 


Diagnosing 

One of the most desirable operations that 
can be performed on a system is that of 
diagnosis, the process of determining 
which components are causing the system 


to behave in an incorrect manner. The way 
our shell's diagnoser does this is by 
gathering a list of all objects which 
could affect the discrepant measurement 
(see "Monitoring” above) and eliminating 
those whose failure can't account for the 
anomaly. (We liken this process to that 
of a "mind game"- "If object A failed 
then it would cause B, C and D to read b, 
c and d. Since they're not, A must be 
OK"). If, after processing all control- 
ling components only one is left, then it 
must be the culprit. Otherwise you're 
left with a list of suspects, any one of 
which could be failing. (Our diagnoser 
only checks for single points of failure, 
not simultaneous, unrelated multiple 
failures. The claim can be made that, at 
least with most systems at KSC, single 
point failures are the norm and simulta- 
neous, unrelated multiple failures rare 
[3]). For more information on diagnosing 
see Scarl [4] . 


Simulating and Training 


Because the knowledge base describes the 
system's components and operation as ac- 
curately as possible, our system is by 
definition a high-fidelity model. Our 
shell uses this model inherently in mon- 
itoring and diagnosing but has another 
copy of the knowledge base which runs in 
parallel to the first and acts as the 
real-world system. Objects (components) 
can be failed and the simulator process 
will propagate the failure through its 
knowledge base, sending the affected mea- 
surements to the constraints (monitoring) 
system just like the real system would. 
This allows you to develop the knowledge 
base (and currently for us the shell) 
without being physically connected to the 
system. Also, operators can be trained on 
this system which (if modelled correctly) 
will perform just as if connected to the 
hardware. 


Controlling 

In traditional control and monitor soft- 
ware the methods of controlling each com- 
ponent of interest are directly and ex- 
plicitly coded. With the approach used in 
KATE, a more declarative style of control 
is available. Instead of telling the pro- 
gram exactly how to accomplish the con- 
trol goal you can simply request any ob- 
ject (command, measurement, component or 
pseudo-object such as an internal pres- 
sure) to be in any state. The control 

portion of the shell searches backwards 
in the knowledge base from the component 
to the controlling commands, building a 
context-sensitive (uses current component 
states) math expression along the way. 
This math model is used to construct any 
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and all possible combinations of commands 
that would give you the desired state* 
Any combinations which violate previous 
requirements (see "Maintaining" below) 
are not allowed. Currently, the KATE 
shell automatically uses the option which 
requires the fewest number of commands*. 
What this means is the low-level 
(component-level) control is automati- 
cally done for you. Upon this low-level 
base will be built a very high-level 
control language whose statements would 
read just like a procedure describing the 
desired operation of the system. For ex- 
ample: "Maintain AFT-DUCT-FLOW at 25 
LBS/MIN for 15 MINUTES". 


Maintaining 

If it is desired to maintain a particular 
object in a particular state (like a 
purge-pressure at some value) you can get 
it to that state and keep the fact that 
it's to be maintained on a list. In the 
future, any diagnosis that indicates the 
failed component(s) effect that main- 
tained object, the control code can be 
automatically run again to reinstate that 
now-violated request. (Recall the control 
portion is context-sensitive which in- 
cludes not using failed components). 


Drawing 

The structure information in the knowl- 
edge base gives you much of what you need 
to draw engineering-style schematic dia- 
grams. Once drawn, the actual values for 
each measured component (as well as in- 
ferred values for all others) can be dis- 
played dynamically, creating a "live" 
drawing. If system-grouping information 
is supplied or can be inferred, the dis- 
plays can be on a functional level with 
the operator able to request the "level" 
of viewing. For example, a valve with all 
its supporting circuitry, commands and 
measurements can be displayed by itself 
on the screen, or a number of valves with 
just their significant measurements 
(perhaps position) shown. The drawing 
also allows the user to do control by 
pointing and clicking the computer's 
mouse on any component and inputting a 
desired value. 


Single Point Failure Analyzing 

Since the control portion of the KATE 
shell accumulates all possible combina- 


*This is not the final way KATE will 
chose which option to use; there are 
usually natural priorities and 
requirements that would constrain the 
selection and would be integrated into 
the control code. 


tions of commands to achieve a particular 
goal, its routines can be run on each 
component to produce a list of components 
which are single points of failure, i.e. 
they operate without redundancy. This 
single point failure analysis program 
could be run dynamically after each diag- 
nosed failure to give a running account 
of system vulnerability. 


Knowledge Base Generation from CAD Files 

Because this entire approach is based on 
the knowledge base, it is vital that it 
is as correct and as complete as possi- 
ble. To aid the system developer in this, 
much of the knowledge base creation task 
can be accomplished automatically by a 
program which uses CAD-generated drawing 
information. 


Automatic Documentation/Retrieval 

Since any information can be stored with 
each object in the knowledge base, it 
provides a very convenient way to have 
component documentation (specification 
sheets, failure histories, ven- 
dor/supplier data) and digitized video 
very easily accessible on-line. 


THE KATE IMPLEMENTATION 


Many of the features listed above have 
been embodied in the KATE project at the 
Kennedy Space Center. KATE is an expan- 
sion of an earlier joint MITRE/KSC pro- 
ject called LES, or LOX (Liquid Oxygen) 
Expert System. LES is a real-time monitor 
and diagnosis expert system which was 
used to successfully monitor six Space 
Shuttle LOX loadings at the Space Center. 
Scarl [4] and Scarl [5] describe LES's 
capabilities and methods in detail. 

The KATE shell is implemented using a 
modified version of frames and the Frame 
Representation Language [6] to represent 
and access the knowledge base. It runs on 
both AT-class microcomputers (for demon- 
strations) and Lisp machines, the latter 
being used for further development. The 
code is written entirely in Common Lisp, 
with extensions used for the user inter- 
face and multi-tasking. As of this writ- 
ing, the KATE shell exhibits monitoring, 
goal-seeking control/maintenance and di- 
agnosis of failures for objects without 
state or feedback. In the control and di- 
agnostic portion of the shell, work is 

being done to handle components which 
utilize feedback and internal state in 
their operation and control loops. Work 
has just begun to update KATE's drawing 
system to do completely automatic 
schematic diagram generation and display. 
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A plotting system is functioning which is 
smart about how to plot all measurements 
related to a particular measurement or 
component. Work is also progressing on a 
program to do single point failure analy- 
sis and generation of KATE-compatible 
knowledge bases from standard CAD drawing 
files . 

Current development of the KATE shell is 
being done in order to provide an opera- 
tional control, monitor and diagnostic 
system for the Environmental Control 
System (ECS) in the Orbiter Maintenance 
and Refurbishment Facility ( OMRF ) which 
is currently under construction. This 
building will be used for storing Space 
Shuttle Orbiters and doing maintenance 
work on them and the ECS system will pro- 
vide a conditioned flow of air to four 
areas of the orbiter for the purposes of 
ventilation, cooling, and controlling 
static electrical discharge. Because the 
OMRF ECS system consists of many kinds of 
components not currently handled by KATE, 
the development of its knowledge base is 
driving expansion of the shell's capa- 
bilities. This will be the first opera- 
tional real-time control and monitor ex- 
pert system at KSC and it has the poten- 
tial of being included in other projects 
at the Space Center. 


LIMITATIONS 


Although the systems the KATE shell has 
been applied to have been mostly electro- 
mechanical in nature (pumps, valves, re- 
lays, discrete and analog commands and 
measurements) it can be applied to many 
others. However, there are some cases and 
conditions where this approach might not 
be appropriate. (Those related to speed 
or efficiency might be addressed by 
faster computers or more efficient code) : 

Poorly Understood Systems - Since the KATE 
shell relies entirely on a very accu- 
rate description of the system, the 
systems which it can handle must be 
well understood in terms of identifying 
each component, how the components work 
and exactly how they are connected, for 
example an electrical circuit. A bio- 
logical system (like the human body), 
since its functioning is not well un- 
derstood, would not be a good candidate 
for this type of representation and 
modeling. However, you can model ab- 
stract concepts and you can model on 
different levels of abstraction with 
KATE, assuming you understand how those 

concepts or "boxes" interact and func- 
tion on the level being modelled. 

High Speed Systems - The systems we have 
applied KATE to have had significant 
measurement changes occurring about 
once per second. The reaction times 


displayed have been on the order of a 
maximum one second delay from the time 
when a measurement changes to the time 
when the shell can react with a command 
issuance. Diagnosis times are around 
four seconds for our most complex exam- 
ple* and we expect the maximum to drop 
to around one second. 

"Broad" Systems - Since KATE's searching 
is depth- sensitive , it is most effi- 
cient for systems which have a small 
number of components between commands 
and measurements. Systems such as LOX 
fit this description with mostly four 
or five components between commands and 
measurements (one branch) but many 
copies of those branches repeated 
throughout the system for redundancy. 

Poorly Instrumented Systems - Because 
KATE , like an engineer, uses supporting 
measurements for detecting faults and 
eliminating faulty components during a 
diagnosis, it needs good system visi- 
bility. The more measurements avail- 
able, the better the shell (or an engi- 
neer) can detect the presence of a mis- 
behaving component and determine ex- 
actly which component it is. 


FUTURE 


KATE could be applied to, and could have 
a positive impact on, many projects at 
the Space Center as well as in other 
control and monitor applications. What 
follows is a description of some possible 
application areas as well as a few future 
KSC projects and how they could benefit 
from model-based technology: 

Ground Data Management System (GDMS) - 
GDMS is a _ major project being developed 
at KSC to support interface verifica- 
tion, integration and test activities 
for the various elements of the Space 
Station, from prelaunch on, at the 
Space Center. It will process and test 
Space Station "work package" items, 
interfaces broken for shipping, inter- 
faces between different launch package 
items, and interfaces between the 
launch package and the orbiter. GDMS 
consists of a large multi-channel net- 
work system, each channel capable of 
handling about ten times as many com- 
mands and measurements as the current 
LPS. Each channel can support up to 256 
mini/Mainf rame computers acting as ap- 
plication processors and up to 256 en- 
gineering workstations for graphics and 
display processing. Each processor will 
also have access to large archival and 

retrieval subsystems, database systems. 


*The LOX replenish valve is a very 
redundant subsystem which has around 20 
components and 12 commands and 
measurements associated with it. 
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documentation processing, and other 
networks via gateways and bridges. The 
KATE shell could be the application 
doing the test and check-out job on the 
application processors. Since the ele- 
ments will probably be very different 
from one another and will have to be 
tested before integration, trying to do 
so with conventional software technolo- 
gy would require a tremendous effort. 
Even if this is possible, the effort 
would not be applicable to other ele- 
ments. With the knowledge-based ap- 
proach, because only the knowledge base 
would have to be developed by the ex- 
perimenter or vendor (probably from a 
CAD system), application code would 
never have to be written. 

Heavy Lift Launch vehicle - A check-out 
and control system wiliT^ need to be cre- 
ated for the future heavy lift launch 
vehicle(s) being planned by NASA and 
the Air Force. The types of test and 
check-out tasks that need to be per- 
formed for this will be very similar to 
those done by LPS (and GDMS) and 
therefore could benefit greatly by em- 
ploying some of the ideas in the KATE 
shell • 

Electric Power and Research Institute 
( EPRI ) - Currently, a NASA technology 
transfer program is underway with EPRI 
to apply the KATE shell to problems in 
the power industry and nuclear power 
plants in particular. Early investiga- 
tion and interviews with plant managers 
have identified many areas where KATE 
could offer substantial savings and 
safety features. 

Other Applications - Other areas which 
could benefit from the approach taken 
in KATE include on-board aircraft, ship 
and spacecraft systems, the Space Sta- 
tion, satellites and the National 
Aerospace Plane. 


Conclusion 

We feel that a knowledge-based control 
and monitor approach, such as exemplified 
by KATE, may be the only solution to 
problems where the systems under test are 
well understood, can be described in a 
structure-function format and it is de- 
sirable to do automated control, monitor, 
diagnosis, drawing, sensor validation and 
redundancy management on them. For large 
systems requiring diagnostics, tradition- 
al tree-structured methods are impracti- 
cal, for identifying all possible failure 
states can easily become an impossible 
task. Having the low-level control per- 
formed automatically by the shell pro- 
vides the basis for a very high-level 
procedural language which would eliminate 
or greatly simplify application program 
writing as we know it today, saving de- 
velopment time and money and providing 


features impossible to achieve with cur- 
rent methods. 
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ACRONYMS 


ECS Environmental Control System 
EPRI Electric Power and Research 
Institute 

FD Function Designator 

GDMS Ground Data Management System 
GOAL Ground Operations Aerospace 
Language 

KATE Knowledge-based Autonomous Test 
Engineer 

KSC Kennedy Space Center 

LES LOX Expert System 

LOX Liquid Oxygen 

LPS Launch Processing System 

OMRF Orbiter Maintenance and 

Refurbishment Facility 
SGOS Shuttle Ground Operations Simulator 
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